Avoid vendor lock-in risk with multi-cloud deployments

Avoid vendor lock-in risk with multi-cloud deployments

As businesses outsource their infrastructure to public cloud providers they are in turn taking on major risks. In a recent piece by Financial News (gated), senior executives at Goldman Sachs and Standard Chartered warned that an overreliance on a small band of cloud service providers could result in a major hack or outage wreaking havoc on the global banking system.

Lock-in is a global issue: Bain’s Cloud Computing Survey noted that the share of respondents citing vendor lock-in as a “top three concern” grew from 7% to 23% from 2012 to 2015. Of course, cloud vendor lock-in issues extend beyond uptime risk; they also include the regulatory risk of changes in data sovereignty policies or the financial risk of having to endure price hikes without any negotiating power; Dropbox went so far as to migrate off of AWS and onto their own system to get control of their costs.

Fortunately, CockroachDB can help eliminate these problems by enabling seamless multi-cloud deployments.

Multi-cloud deployments hedge risk

On stage at the 2017 OpenStack Summit, representatives from some of the top cloud providers including IBM, vmWare, and Red Hat set up a multi-cloud CockroachDB cluster. As servers joined the network, their new peers continually shared information about the cluster and collectively guaranteed clients would get the exact same results no matter which node was queried.

A CockroachDB cluster operates as a self-healing, elastic data layer than can span private and public clouds alike, enabling services to survive a node, data center, or even an entire cloud provider going down without experiencing downtime or lost data. Using CockroachDB means shifting operational thinking from disaster recovery to disaster resilience, and completely side steps the risks associated with vendor lock-in.

Retaining data control

Helping companies of all sizes avoid vendor lock-in is top of mind for us; that’s one of the reasons why we built CockroachDB from the ground up to run on commodity hardware, keeping the choice of where and how data is managed in the hands of IT teams.

In the Financial News article, a Standard Chartered executive pondered if other players would emerge to help eliminate this systematic risk of cloud vendor lock-in. We think CockroachDB answers the call.

Photo by Alex Holyoake on Unsplash

About the author

Nate Stewart

Nate is the Chief Product Officer at Cockroach Labs. Prior to Cockroach Labs, he built the NYC product management organization for the venture-backed marketing SaaS company, Percolate. Outside of product, his experience spans engineering and business. Nate was a lead backend software developer at Bloomberg L.P. and received his MBA from MIT.

Keep Reading

CockroachDB on DC/OS: Resilient and hassle-free operations for global services

CockroachDB makes data easier to manage by providing a strongly-consistent, highly-scalable, SQL interface that …

Read more
A tale of two ports | Cockroach Labs

CockroachDB is pretty easy to deploy. We’ve done our best to avoid the need for configuration files, …

Read more